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This is in response to the appeal brief filed September 11, 2009, appealing from the 
Office action mailed October 29, 2008. 
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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on 
the Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is substantially 
correct. 

The Examiner also asserts, that claims 22 and 26, as may best be understood, 
stand rejected under 35 U.S.C. 103(a) as being unpatentable over Gray in view of 
Buckley and Chou and further in view of U.S. Patent No. 4,866,71 3 to Worger et al. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 



Application/Control Number: 09/913,992 Page 3 

Art Unit: 2857 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 



(8) Evidence Relied Upon 



6,370,449 


RAZAVI etal. 


4-2002 


6,512,968 


DE BELLEFEUILLE et al. 


1-2003 


6,330,499 


CHOU et al. 


12-2001 


5,465,207 


BOATWRIGHT etal. 


11-1995 


5,964,813 


ISHII etal. 


10-1999 


6,185,491 


GRAY etal. 


2-2001 


6,246,935 


BUCKLEY 


6-2001 


4,866,713 


WORGER etal. 


09-1989 



(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 



Claim Rejections - 35 USC §112 

The following is a quotation of the first paragraph of 35 U.S.C. 112: 
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The specification shall contain a written description of the invention, and of the manner and process of 
making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the 
art to which it pertains, or with which it is most nearly connected, to make and use the same and shall 
set forth the best mode contemplated by the inventor of carrying out his invention. 

Claims 11, 12, 14, and 16-23 are rejected under 35 U.S.C. 112, first paragraph, 
as failing to comply with the enablement requirement. The claim(s) contains subject 
matter which was not described in the specification in such a way as to enable one 
skilled in the art to which it pertains, or with which it is most nearly connected, to 
make and/or use the invention. 

Claims 11 and 19 are rejected as lacking enablement because they each require 
"performing an error diagnosis of software running on the other components" and 
"allowing a remote diagnosis of the other components of the distributed system to be 
carried out, wherein the remote diagnosis includes testing at least one of the other 
components." 

The specification best describes these features in the following passages: 

First on page 5, lines 13-15: 

In addition, service element 2 allows a service provider to carry out a remote 
diagnosis of the individual components, using communication means 4. This 
service provider can then test the individual components directly, using 
communication means 4 and service element 2. 

This section, while mentioning a service provider carrying out remote diagnosis 
and testing, does not enable one having ordinary skill in the art to use both the 
remote testing and the remote diagnosis. Specifically, by not mentioning any steps 
to be carried out regarding the test, one having ordinary skill in the art would not 
understand, and therefore would not be able to perform, the manner for testing. 
Additionally, this section makes it unclear to one having ordinary skill in the art how 
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the remote diagnosis and testing differ and raises the issue as to whether or not the 

remote diagnosis and testing are indeed different from each other. The claims, 

however, by requiring "allowing a remote diagnosis. ..wherein the remote diagnosis 

includes testing", indicate that diagnosing and testing are different from each other. 

The specification then further elaborates the operation of the service provider on 

page 5, lines 17-23 by only discussing the remote diagnosis, thereby again raising 

the question as to what constitutes the testing operation and how the testing differs 

from the remote diagnosis, specifically: 

Service element 2 also contacts the service provider, using communication 
means 4, when service element 2 can no longer eliminate an error itself. If the 
component in question can also no longer be repaired using the remote 
diagnosis of the service provider, then the service provider contacts the user of 
the distributed system, using communication means 4, in order to request that he 
or she visit a repair shop. Display 7 and/or communication means 4 is used for 
this. As an alternative, the audio playback of the car radio, which includes DAB 
receiver 6, can be used. 

The specification then discloses, on page 7, lines 10-19, performing a functional 

test, but refers to the testing as being performed by the local service element, and 

not by a remote means, thereby making it unclear to one having ordinary skill in the 

art whether this testing is considered to be the remote testing, specifically: 

A method known for this is the checksum method. CRC (cyclical redundancy 
check) sums are calculated using code segments of the software, and are 
compared. In this manner, an incorrect code can be identified, and, if the 
remaining software of the service element has the independent capability, then 
the software can be repaired, e.g. by loading new software parts, so-called 
patches. In the case of serious software errors of service element 2, an 
emergency operation of service element 2 can ensure the correction. A functional 
test of the bus communication can be carried out using predefined signals, which 
are transmitted on the bus, and to which a certain response from the connected 
components is expected, this response being known to service element 2. This 
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ensures that an error message of a subsystem is not lost due to a bus 
interruption. 

Finally, the specification, on page 7, line 28 to page 8, line 3 discusses testing 

with respect to the remote service provider, specifically: 

Service element 2 questions a service provider in certain time intervals, e.g. 
once a month, if new software versions are available for the individual 
components of the distributed system. If this is the case, the service element 
requests such a new software version, and then loads it using communication 
means 4. The new software version is tested for errors, using test vectors, and is 
then configured for the corresponding components. Such an upgrade is then the 
specific software, or also the manufacturer of the components. It can also be a 
service company, which takes over the distribution of the software and the 
maintenance tasks. 



However, this section does not remedy the lack of enablement of the claimed 
limitations because is discusses the testing as testing the new software version for 
errors. The claimed limitations in question require "performing an error diagnosis of 
software running on the other components" and "allowing a remote diagnosis of the 
other components of the distributed system to be carried out, wherein the remote 
diagnosis includes testing at least one of the other components", and therefore it is 
unclear to one having ordinary skill in the art whether the discussed testing of the 
new software version for errors is with reference to the claimed "performing an error 
diagnosis of software running on the other components" or "remote. . .diagnosis of 
the other components". 

For these reasons, the Examiner asserts that one having ordinary skill in the art 
would not be enabled to make/use the claimed "performing an error diagnosis of 
software running on the other components" and "allowing a remote diagnosis of the 
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other components of the distributed system to be carried out, wherein the remote 
diagnosis includes testing at least one of the other components" as required by 35 
U.S.C. 112, first paragraph. 

Claims 12, 14, 16-18 and 20-23 are rejected under 35 U.S.C. 112, first 
paragraph, because they incorporate the lack of enablement present in their 
respective parent claims. 

Claim 26 is rejected under 35 U.S.C. 112, first paragraph, as failing to comply 
with the written description requirement. The claim(s) contains subject matter which 
was not described in the specification in such a way as to reasonably convey to one 
skilled in the relevant art that the inventor(s), at the time the application was filed, 
had possession of the claimed invention. 

Claim 26 is rejected as failing to comply with the written description requirement 
because, as amended/presented, it requires, "a processing device disposed in the 
motor vehicle and adapted to perform operations including the operations of: 
automatically, and at predefined intervals, performing an error diagnosis of software 
running on the other components; for each of a first subset of errors diagnosed in 
the error diagnosis step, repair the error; and for each of a second subset of errors 
diagnosed in the error diagnosing step, contact a provider and allow the provider to 
responsively remotely repair the error." 

The specification, however, on page 5, lines 13-23 recites: 

In addition, service element 2 allows a service provider to carry out a remote 
diagnosis of the individual components, using communication means 4. This 
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service provider can then test the individual components directly, using 
communication means 4 and service element 2. 

Service element 2 also contacts the service provider, using communication 
means 4, when service element 2 can no longer eliminate an error itself. If the 
component in question can also no longer be repaired using the remote 
diagnosis of the service provider, then the service provider contacts the user of 
the distributed system, using communication means 4, in order to request that he 
or she visit a repair shop. Display 7 and/or communication means 4 is used for 
this. As an alternative, the audio playback of the car radio, which includes DAB 
receiver 6, can be used. 



The Examiner asserts that this section does suggest that the service element 
(i.e. processing device disposed in the motor vehicle) can both repair errors and, if 
an error is obtained that cannot be repaired, contact a provider and allow the 
provider to responsively remotely repair the error by disclosing "[s]ervice element 2 
also contacts the service provider, using communication means 4, when service 
element 2 can no longer eliminate an error itself. 

This section, however, also explicitly indicates that the "service element 2 allows 
a service provider to carry out a remote diagnosis of the individual components, 
using communication means 4" and "[t]his service provider can then test the 
individual components directly, using communication means 4 and service element 
2". This section, therefore, indicates that it is the service provider that carries out a 
remote diagnosis and does not support a local error diagnosis by the on-vehicle 
processing device nor that the diagnosis is an error diagnosis of software, as 
required by claim 26. 

With respect to error diagnosis of software, the specification indicates on page 7, 
line 6 to page 8, line 3: 
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In regular intervals, service element 2 checks the components, which are 
connected to bus 1 , and to which service element 2 also belongs. Therefore, a 
self-diagnosis is also carried out. This self-diagnosis, which is performed by 
software, is carried out using a suitable method. 

A method known for this is the checksum method. CRC (cyclical redundancy 
check) sums are calculated using code segments of the software, and are 
compared. In this manner, an incorrect code can be identified, and, if the 
remaining software of the service element has the independent capability, then 
the software can be repaired, e.g. by loading new software parts, so-called 
patches. In the case of serious software errors of service element 2, an 
emergency operation of service element 2 can ensure the correction. A functional 
test of the bus communication can be carried out using predefined signals, which 
are transmitted on the bus, and to which a certain response from the connected 
components is expected, this response being known to service element 2. This 
ensures that an error message of a subsystem is not lost due to a bus 
interruption. 

If service element 2 detects an error, then service element 2 contacts a 
service provider using communication means 4, in order to load corrected 
software and consequently configure the specific components of the distributed 
system. But if there is a hardware error, then service element 2 initially sends a 
message to a service provider, who then contacts the user, so that the 
components in question are replaced or repaired. This error diagnosis is 
conducted in certain time intervals, e.g. once a day or every week or once a 
month. 

Service element 2 questions a service provider in certain time intervals, e.g. 
once a month, if new soft-ware versions are available for the individual 
components of the distributed system. If this is the case, the service element 
requests such a new software version, and then loads it using communication 
means 4. The new software version is tested for errors, using test vectors, and is 
then configured for the corresponding components. Such an upgrade is then 
automatically carried out by the visitor alone. A service provider can be the 
manufacturer of the specific software, or also the manufacturer of the 
components. It can also be a service company, which takes over the distribution 
of the software and the maintenance tasks. 



The Examiner asserts that this section, does support the claimed limitations of "a 
processing device disposed in the motor vehicle and adapted to perform operations 
including the operations of: automatically, and at predefined intervals, performing an 
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error diagnosis of software running on the other components" by providing a service 
element that periodically performs a CRC. 

With respect to error correction (i.e. repair), this section, however, indicates that 
"the software can be repaired, e.g. by loading new software parts, so-called patches" 
wherein such repair is disclosed as "[i]f service element 2 detects an error, then 
service element 2 contacts a service provider using communication means 4, in 
order to load corrected software and consequently configure the specific 
components of the distributed system" or "if there is a hardware error, then service 
element 2 initially sends a message to a service provider, who then contacts the 
user, so that the components in question are replaced or repaired." This section, 
therefore, indicates that if a first subset of errors is diagnosed, the service element 
contacts a service provider to repair the error and if a second subset of errors is 
diagnosed, the service provider is also contacted, but in this instance a user is 
further contacted so that the components in question can be replaced or repaired. 

This does not support a limitation of "a processing device disposed in the motor 
vehicle and adapted to perform operations including the operations of... for each of a 
first subset of errors diagnosed in the error diagnosis step, repair the error; and for 
each of a second subset of errors diagnosed in the error diagnosing step, contact a 
provider and allow the provider to responsively remotely repair the error" because for 
the first subset of errors, it is still the service provider that is remotely contacted to 
upload corrected software to repair the error and, for the second subset of errors, a 
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user is contacted to manually repair the error locally rather than performing such 
repair by the provider remotely. 

Additionally, this second subset of errors corresponds to a hardware error and, 
therefore, does not properly support determining a second subset of errors based on 
"performing an error diagnosis of software running on the other components". 

For these reasons, the Examiner asserts that the specification does not 
adequately support "a processing device disposed in the motor vehicle and adapted 
to perform operations including the operations of: automatically, and at predefined 
intervals, performing an error diagnosis of software running on the other 
components; for each of a first subset of errors diagnosed in the error diagnosis 
step, repair the error; and for each of a second subset of errors diagnosed in the 
error diagnosing step, contact a provider and allow the provider to responsively 
remotely repair the error" and, as such, claim 26 contains subject matter which was 
not described in the specification in such a way as to reasonably convey to one 
skilled in the relevant art that the inventor(s), at the time the application was filed, 
had possession of the claimed invention. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and the 
prior art are such that the subject matter as a whole would have been obvious at the time the invention was 
made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall 
not be negatived by the manner in which the invention was made. 
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Claims 11, 12, 14, 17-20 and 23, as may best be understood, are rejected under 
35 U.S.C. 103(a) as being unpatentable over U.S. Patent No. 6,370,449 to Razavi et 
al. in view of U.S. Patent No. 6,512,968 to de Bellefeuille et al. 

This rejection is based on the claims as may best be understood, due to the 
outstanding 35 U.S.C. 112, first paragraph, rejections, specifically, due to the lack of 
enablement of "performing an error diagnosis of software running on the other 
components" and "allowing a remote diagnosis of the other components of the 
distributed system to be carried out, wherein the remote diagnosis includes testing at 
least one of the other components" in independent claims 1 1 and 19. 

With respect to claim 1 1 , Razavi discloses a service element that belongs to a 
distributed system in a motor vehicle as a component (column 6, lines 10-18), the 
distributed system further including other components that are independent of one 
another (column 3, lines 30-33) and interconnected by a bus (column 4, lines 40-47), 
the service element comprising a processing device disposed in the motor vehicle 
(column 8, lines 21-49) and adapted to perform operations including the operations 
of configuring the other components (column 7, lines 40-46, column 8, lines 21-29, 
and column 1 1 , lines 1 4-20), maintaining the other components (column 1 3, lines 
53-61 and column 15, lines 6-13), allowing a remote diagnosis of the other 
components of the distributed system to be carried out (column 15, lines 3-10), and 
performing an emergency function (column 1, lines 41-46 and column 7, lines 54- 
63). 
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With respect to claim 12, Razavi discloses that the processing device is further 
adapted to perform the operations of detecting a new component and for integrating 
the new component into the distributed system (column 9, lines 45-54) and operating 
a display device to represent information about a configuration (column 10, line 46 to 
column 11, line 12). 

With respect to claim 14, Razavi discloses that at least one of the maintaining 
operation and the correcting operation includes communicating with a 
communication element for loading new software for the other components (column 
13, lines 61-64). 

With respect to claim 17, Razavi discloses that the processing device is further 
adapted to perform the operations operating a display to transfer information about 
the distributed system to a user of the distributed system (column 1 1 , lines 1 4-20) 

With respect to claim 19, Razavi discloses a distributed system, comprising 
components connected by a bus (column 4, lines 40-47) the components being 
independent of each other and being disposed in a motor vehicle (column 3, lines 
30-33), one of the components being a service element (column 6, lines 10-18) that 
includes a processing device adapted to perform operations (column 8, lines 21-49), 
the operations including configuring the other components (column 7, lines 40-46, 
column 8, lines 21-29, and column 11, lines 14-20), maintaining the other 
components (column 13, lines 53-61 and column 15, lines 6-13) allowing remote 
diagnosis of the other components of the distributed system to be carried out 
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(column 15, lines 3-10), and performing an emergency function (column 1, lines 41- 
46 and column 7, lines 54-63). 

With respect to claim 20, Razavi discloses that at least one of the other 
components includes a communication element (column 4, lines 54-60 and column 
5, line 51). 

With respect to claim 23, Razavi discloses that the bus includes one of an 
electrical wiring system, an optical wiring system, and a radio based system (column 
3, lines 53-57). 

As noted above, the invention of Razavi teaches many of the features of the 
claimed invention and while the invention of Razavi does teach uploading new 
software and performing maintenance and updates of existing software of the other 
components when necessary, Razavi does not explicitly describe the manner in 
performing maintenance, specifically by performing an error diagnosis to check the 
software in accordance with a predetermined value. 

De Bellefeuille teaches a computerized automotive service system comprising 
means for maintaining installed software, as part of an installation/uninstallation 
feature (column 10, lines 11-13), including an arrangement for performing integrity 
testing and error diagnosis of software by checking the software in accordance with 
a predetermined value in order to carry out the corrective maintenance (column 1 1 , 
lines 12-25). 

It would have been obvious to one having ordinary skill in the art to modify the 
invention of Razavi to explicitly include performing an error diagnosis to check the 
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software in accordance with a predetermined value, as taught by de Bellefeuille, 
because the combination would have provided a corresponding method for 
performing the maintenance of Razavi as part of the software updates that would 
have improved the operation of Razavi by periodically checking the integrity of the 
software of the other components to prevent incorrect operation due to software 
errors (column 11, lines 12-25). 

Claim 16, as may best be understood, is rejected under 35 U.S.C. 103(a) as 
being unpatentable over Razavi et al. in view de Bellefeuille and further in view of 
U.S. Patent No. 6,330,499 to Chou et al. 

This rejection is based on the claims as may best be understood, due to the 
outstanding 35 U.S.C. 112, first paragraph, rejections, specifically, due to the lack of 
enablement of "performing an error diagnosis of software running on the other 
components" and "allowing a remote diagnosis of the other components of the 
distributed system to be carried out, wherein the remote diagnosis includes testing at 
least one of the other components" in independent claims 1 1 and 1 9. 

As noted above, the invention of Razavi and de Bellefeuille teaches many of the 
features of the claimed invention and while the invention of Razavi and de 
Bellefeuille does teach a communication element for loading new software for the 
other components as well as performing an error diagnosis of the software, the 
combination does not explicitly include communicating with a communications 
element for, in the case of a serious functional error, contacting a service provider. 
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Chou teaches a system and method for vehicle diagnostics and health 
monitoring including an in-vehicle computing system (column 2, lines 55-63) 
connected to a plurality of elements on a bus (column 3, lines 33-37 and column 6, 
lines 55-56) and an arrangement for allowing a remote diagnosis of the system 
(column 3, lines 15-31) and a communications element for, in the case of a serious 
functional error, contacting a service provider (column 5, lines 16-24 and column 7, 
lines 4-26). Chou also teaches coupling the processor through a communicating 
transceiver for communicating over a radio channel to further devices such as a 
notebook computer (column 3, lines 47-53). 

It would have been obvious to one having ordinary skill in the art to modify the 
invention of Razavi and de Bellefeuille to explicitly include communicating with a 
communications element for, in the case of a serious functional error, contacting a 
service provider, as taught by Chou, because, as suggested by Chou, the 
combination would have aided the user of the system by providing trouble-shooting, 
diagnosis, tracking, and recommendations, as well as prevented serious 
consequences (column 1, lines 18-30) and provided emergency responses to an 
emergency condition, such as the condition signaled by the emergency arrangement 
of Razavi and de Bellefeuille (column 7, lines 22-26). 

Claim 21, as may best be understood, is rejected under 35 U.S.C. 103(a) as 
being unpatentable over Razavi et al. in view de Bellefeuille and further in view of 
U.S. Patent No. 5,465,207 to Boatwright et al. 
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This rejection is based on the claims as may best be understood, due to the 
outstanding 35 U.S.C. 112, first paragraph, rejections, specifically, due to the lack of 
enablement of "performing an error diagnosis of software running on the other 
components" and "allowing a remote diagnosis of the other components of the 
distributed system to be carried out, wherein the remote diagnosis includes testing at 
least one of the other components" in independent claims 1 1 and 1 9. 

As noted above, the invention of Razavi and de Bellefeuille teaches many of the 
features of the claimed invention and while the invention of Razavi and de 
Bellefeuille does teach a communication element as a transceiver station (i.e. 
modem) (Razavi; column 11, lines 38-42), the combination does not explicitly 
indicate that the transceiver station communicates over a radio channel. 

Boatwright teaches a vehicle data system including a plurality of system 
components connected to a bus (Figure 4) wherein one of the components is a 
communication element comprising a transceiver station (i.e. modem) 
communicating over a radio channel (column 6, lines 62-66). 

It would have been obvious to one having ordinary skill in the art to modify the 
invention of Razavi and de Bellefeuille to explicitly indicate that the transceiver 
station communicate over a radio channel, as taught by Boatwright, because 
Boatwright suggests that the combination would have provided a communication 
protocol for the modem of Razavi and de Bellefeuille that is a common manner of 
communication for modems (column 6, lines 62-66). 
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Claim 22, as may best be understood, is rejected under 35 U.S.C. 103(a) as 
being unpatentable over Razavi et al. in view de Bellefeuille and further in view of 
U.S. Patent No. 5,964,813 to Ishii et al. 

This rejection is based on the claims as may best be understood, due to the 
outstanding 35 U.S.C. 112, first paragraph, rejections, specifically, due to the lack of 
enablement of "performing an error diagnosis of software running on the other 
components" and "allowing a remote diagnosis of the other components of the 
distributed system to be carried out, wherein the remote diagnosis includes testing at 
least one of the other components" in independent claims 1 1 and 1 9. 

As noted above, the invention of Razavi and de Bellefeuille teaches many of the 
features of the claimed invention and while the invention of Razavi and de 
Bellefeuille does teach performing an error diagnosis of the software any time that it 
is desired (de Bellefeuille; column 11, lines 20-25), the combination does not 
explicitly indicate that the error diagnosis is performed at a predefined time interval. 

Ishii teaches a vehicle diagnostic data storing system comprising means for 
performing error diagnosis wherein the diagnosis is performed at a predetermined 
time interval (column 4, lines 48-61). 

It would have been obvious to one having ordinary skill in the art to modify the 
invention of Razavi and de Bellefeuille to explicitly indicate that the error diagnosis is 
performed at a predefined time interval, as taught by Ishii, because, as suggested by 
Ishii, the combination would have improved the system of Razavi and de Bellefeuille 
by providing automatic and periodic error diagnosis to reduce the burden of the user 



Application/Control Number: 09/913,992 Page 19 

Art Unit: 2857 

having to initiate the diagnosis while reducing the chance of system error through 
diagnostics occurring more often (column 4, lines 48-61). 

Claim 26, as may best be understood, is rejected under 35 U.S.C. 103(a) as 
being unpatentable over Razavi et al. in view de Bellefeuille and Chou et al. and 
further in view of U.S. Patent No. 5,964,81 3 to Ishii et al. 

This rejection is based on the claim as may best be understood, due to the 
outstanding 35 U.S.C. 112, first paragraph, rejection, specifically, due to the lack of 
written description regarding "a processing device disposed in the motor vehicle and 
adapted to perform operations including the operations of: automatically, and at 
predefined intervals, performing an error diagnosis of software running on the other 
components; for each of a first subset of errors diagnosed in the error diagnosis 
step, repair the error; and for each of a second subset of errors diagnosed in the 
error diagnosing step, contact a provider and allow the provider to responsively 
remotely repair the error" in independent claim 26. 

As noted above, the invention of Razavi, de Bellefeuille, and Chou teaches many 
of the features of the claimed invention and while the invention of Razavi, de 
Bellefeuille, and Chou does teach performing an error diagnosis of the software any 
time that it is desired (de Bellefeuille; column 1 1 , lines 20-25), the combination does 
not explicitly indicate that the error diagnosis is performed at a predefined time 
interval. 
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Ishii teaches a vehicle diagnostic data storing system comprising means for 
performing error diagnosis wherein the diagnosis is performed at a predetermined 
time interval (column 4, lines 48-61). 

It would have been obvious to one having ordinary skill in the art to modify the 
invention of Razavi, de Bellefeuille, and Chou to explicitly indicate that the error 
diagnosis is performed at a predefined time interval, as taught by Ishii, because, as 
suggested by Ishii, the combination would have improved the system of Razavi, de 
Bellefeuille, and Chou by providing automatic and periodic error diagnosis to reduce 
the burden of the user having to initiate the diagnosis while reducing the chance of 
system error through diagnostics occurring more often (column 4, lines 48-61). 

Claims 11, 12, 14, 16-21, and 23, as may best be understood, are rejected under 
35 U.S.C. 103(a) as being unpatentable over U.S. Patent No. 6,185,491 to Gray et 
al. in view of U.S. Patent No. 6,246,935 to Buckley and further in view of U.S. Patent 
No. 6,330,499 to Chou etal. 

This rejection is based on the claims as may best be understood, due to the 
outstanding 35 U.S.C. 112, first paragraph, rejections, specifically, due to the lack of 
enablement of "performing an error diagnosis of software running on the other 
components" and "allowing a remote diagnosis of the other components of the 
distributed system to be carried out, wherein the remote diagnosis includes testing at 
least one of the other components" in claims 1 1 and 1 9. 
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With respect to claim 1 1 , Gray discloses a service element that belongs to a 
distributed system in a motor vehicle as a component (column 3, lines 27-32), the 
distributed system further including other components that are independent of one 
another and interconnected by a bus (column 3, lines 27-32 and Figure 2), the 
service element comprising a processing device disposed in the motor vehicle and 
adapted to perform operations (column 3, line 66 to column 4, line 8) including the 
operations of configuring the other components (column 3, lines 36-52 and column 
5, line 55 to column 6, line 1), upgrading/maintaining the other components (column 
4, line 65 to column 5, line 8), and performing an emergency function (column 3, 
lines 52-54). 

With respect to claim 12, Gray discloses that the processing device is further 
adapted to perform the operations of detecting a new component and for integrating 
the new component into the distributed system (column 6, lines 28-53) as well as 
operating a display device to represent information about a configuration (column 5, 
lines 60-64 and Figure 9). 

With respect to claim 14, Gray discloses that at least one of the maintaining and 
the correcting operation includes communicating with a communication element for 
loading new software interfaces for the other components (column 4, line 65 to 
column 5, line 6 and column 6, lines 34-40 and 62-64). 

With respect to claim 17, Gray discloses that the processing device is further 
adapted to perform the operations operating a display to transfer information about 
the distributed system to a user of the distributed system (column 5, lines 32-64). 



Application/Control Number: 09/913,992 Page 22 

Art Unit: 2857 

With respect to claim 19, Gray discloses a distributed system, comprising a bus 
and components connected by the bus, the components being independent of each 
other and being disposed in a motor vehicle (column 3, lines 27-32 and Figure 2), 
one of the components being a service element (column 3, lines 27-32) that includes 
a processing device to perform operations (column 3, line 66 to column 4, line 8) the 
operations including configuring the other components (column 3, lines 36-52 and 
column 5, line 55 to column 6, line 1), upgrading/maintaining the other components 
(column 4, line 65 to column 5, line 8), and performing an emergency function 
(column 3, lines 52-54). 

With respect to claim 20, Gray discloses that at least one of the other 
components includes a communication element (column 4, line 65 to column 5, line 
6 and column 6, lines 34-40 and 62-64). 

With respect to claim 23, Gray discloses that the bus includes one of an electrical 
wiring system, and optical wiring system, and a radio based system (column 2, lines 
55-61, column 3, lines 27-32 and Figure 2). 

As noted above, the invention of Gray teaches all of the features of the claimed 
invention except for including performing an error diagnosis of software running on 
the components, in accordance with a predetermined value, and, in case of an error, 
correcting the software. 

Buckley teaches a vehicle instrument panel computer interface and display 
including a central control node that communicates to a plurality of other 
components (column 2, lines 57-62 and column 3, lines 29-51) and performs an 
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error diagnosis of software running on the plurality of components (column 8, lines 
46-63). Buckley also teaches determining the occurrence of an error in the software 
using a cyclic redundancy check with a checksum value (column 7, lines 38-52 and 
column 9, lines 28-38) (see also FOLDOC Free On-Line Dictionary of Computing, 
"cyclic redundancy check"), memory check (column 9, lines 38-55) and newly 
downloaded software check (column 10, lines 27-33), and, upon the occurrence of 
an error, correcting the software to maintain correct operation (column 9, lines 36-37 
and 41-42 and column 10, lines 27-33) through the updating/upgrading the 
components of the system (column 10, lines 27-43). 

It would have been obvious to one having ordinary skill in the art to modify the 
invention of Gray to include performing an error diagnosis of software running on the 
components, in accordance with a predetermined value, and, in case of an error, 
correcting the software, as taught by Buckley, because the combination would have 
provided a further method for determining when new updates are required, such as 
the updates/upgrades disclosed by Gray, and, as suggested by Buckley, provided a 
method for determining whether the software of the devices are updated, complete, 
and correct thereby insuring correct operation of the distributed system (column 8, 
lines 46-65, column 9, lines 28-30 and column 10, lines 30-33). 

As noted above, the invention of Gray and Buckley teaches many of the features 
of the claimed invention and while the invention of Gray and Buckley does teach 
including a communication element for loading new software interfaces for the 
plurality of components, the combination does not specify that the communication 
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element includes a transceiver station communicating over a radio channel or 
including an arrangement for allowing a remote diagnosis of the plurality of 
components of the distributed system and a communications element for, in the 
case of a serious functional error, contacting a service provider. 

Chou teaches a system and method for vehicle diagnostics and health 
monitoring including an in-vehicle computing system (column 2, lines 55-63) 
connected to a plurality of elements on a bus (column 3, lines 33-37 and column 6, 
lines 55-56) and an arrangement for allowing a remote testing and diagnosis of the 
system (column 3, lines 15-31 and column 5, lines 1-15) and a communications 
element for, in the case of a serious functional error, contacting a service provider 
(column 5, lines 16-24 and column 7, lines 4-26). Chou also teaches coupling the 
processor through a communicating transceiver for communicating over a radio 
channel to further devices such as a notebook computer (column 3, lines 47-53). 

It would have been obvious to one having ordinary skill in the art to modify the 
invention of Gray and Buckley to specify that the communication element includes a 
transceiver station communicating over a radio channel, as taught by Chou, because 
Chou suggests that RF communication is one of a plurality of common 
communication means for interfacing to a plurality of devices thereby providing the 
user with desired method to communicate with the other devices. It also would have 
been obvious to include an arrangement for allowing a remote diagnosis of the 
plurality of components of the distributed system and a communications element for, 
in the case of a serious functional error, contacting a service provider, as taught by 



Application/Control Number: 09/913,992 Page 25 

Art Unit: 2857 

Chou, because the combination would have provided a method for adhering to 
space constraints of the system while still providing detailed monitoring and 
diagnostic functions to insure correct system operation and, as suggested by Chou, 
aided the user of the system by providing trouble-shooting, diagnosis, tracking, and 
recommendations, as well as prevented serious consequences (column 1, lines I8- 
60) and provided emergency responses to an emergency condition, such as the 
condition indicated by the emergency arrangement of Gray (column 7, lines 22-26). 

Claims 22 and 26, as may best be understood, are rejected under 35 U.S.C. 
103(a) as being unpatentable over Gray in view of Buckley and Chou and further in 
view of U.S. Patent No. 4,866,713 to Worgeret al. 

This rejection is based on the claims as may best be understood, due to the 
outstanding 35 U.S.C. 112, first paragraph, rejections, specifically, due to the lack of 
enablement of "performing an error diagnosis of software running on the other 
components" and "allowing a remote diagnosis of the other components of the 
distributed system to be carried out, wherein the remote diagnosis includes testing at 
least one of the other components" in claims 1 1 and 19 and due to the lack of written 
description regarding "a processing device disposed in the motor vehicle and 
adapted to perform operations including the operations of: automatically, and at 
predefined intervals, performing an error diagnosis of software running on the other 
components; for each of a first subset of errors diagnosed in the error diagnosis 
step, repair the error; and for each of a second subset of errors diagnosed in the 
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error diagnosing step, contact a provider and allow the provider to responsively 
remotely repair the error" in independent claim 26. 

As noted above, the invention of Gray, Buckley and Chou teaches many of the 
features of the claimed invention including determining the occurrence of an error in 
the software using a cyclic redundancy check with a checksum value (Buckley; 
column 7, lines 38-52 and column 9, lines 28-38), however, the combination does 
not specify that this error diagnosis is performed at a predefined time interval. 

Worger teaches an operational function checking method and device for 
microprocessors comprising performing a cyclic redundancy check at predefined 
time intervals (i.e. periodically) (column 4, lines 24-29). 

It would have been obvious to one having ordinary skill in the art to modify the 
invention of Gray, Buckley and Chou to specify that the error diagnosis is performed 
at a predefined time interval, as taught by Worger, because the combination would 
have provided a method for determining proper operation periodically over operation 
of the device to insure accurate operation is being performed and, as suggested by 
Worger, the combination would have complied with operation of the system in 
carrying out the testing method (column 4, lines 24-29). 

(10) Response to Argument 

• With respect to the rejection of claims 11, 12, 14, and 16-23 under 35 U.S.C. 
112, first paragraph, as failing to comply with the enablement requirement, Appellant 
argues: 
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With regard to claims 1 1 and 19, the Examiner believes that the specification 
does not adequately describe "performing an error diagnosis of software running 
on the other components" and "allowing a remote diagnosis of the other 
components of the distributed system to be carried out, wherein the remote 
diagnosis includes testing at least one of the other components." Specifically, the 
Examiner objects to (1) "not mentioning any steps to be carried out regarding the 
test" and (2) that "it [is] unclear.., how the remote diagnosis and testing are 
indeed different from each other." The Examiner further states that "one having 
ordinary skill in the art would not be able to perform both remote testing and 
remote diagnosis without undue experimentation as one having ordinary skill in 
the art would consider testing and diagnosis to often cover the same thing and 
therefore would turn to the specification for clarification." Advisory Action of 
February 4, 2009. 

Appellants respectfully assert that one of ordinary skill in the art would be able 
to implement the claimed subject matter without undue experimentation. 
Component diagnosis/testing is known in the art and dependent on the specific 
device being diagnosed/tested. The invention is not "performing an error 
diagnosis" in-and-of-itself, but rather the entire claimed subject matter. To that 
end, the "performing an error diagnosis" is in accordance with the specific 
implementation of the invention, but a diagnosis/testing itself for any particular 
implementation would be understood by one of ordinary skill in the art, without 
having to perform undue experimentation. 

Specifically, with regard to the feature of "allowing a remote diagnosis of the 
other components of the distributed system to be carried out, wherein the remote 
diagnosis includes testing at least one of the other components." It is quite clear 
that "testing... other components" is part of (e.g., a subset of) "a remote diagnosis 
of the other components." This is consistent with the specification that recites 
"service element 2 allows a service provider to carry out a remote diagnosis of 
the individual components, using communication means 4. This service provider 
can then test the individual components directly, using communication means 4 
and service element 2." Substitute Specification at page 5, lines 13-15 (emphasis 
added). Moreover, it is understood from the plain meaning of the terms that 
testing is a subset of carrying out remote diagnosis. To perform a diagnosis 
means to identify the nature or cause of a phenomenon. A step in performing 
such identification may include performing a test. 

The present invention is to a novel arrangement of electrical components that 
allows for remote diagnosis/testing. The actual diagnosis routines and test 
routines are well known in the art, and selected based on context of specific 
implementation. This known feature does not render the inventive arrangement 
as lacking enablement, since a person of ordinary skill in the art would not 
require undue experimentation to select the appropriate diagnosis routines and 
tests for a specific implementation. 
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The Examiner asserts that claims 1 1 and 19 are not sufficiently enabled because 
they each require both "performing an error diagnosis of software running on the 
other components" and "allowing a remote diagnosis of the other components of the 
distributed system to be carried out, wherein the remote diagnosis includes testing at 
least one of the other components." 

The specification best describes these features in the following passages: 

First on page 5, lines 13-15: 

In addition, service element 2 allows a service provider to carry out a remote 
diagnosis of the individual components, using communication means 4. This 
service provider can then test the individual components directly, using 
communication means 4 and service element 2. 

The specification then further elaborates the operation of the service provider on 

page 5, lines 17-23 by only discussing the remote diagnosis, thereby raising the 

question as to what constitutes the testing operation, specifically: 

Service element 2 also contacts the service provider, using communication 
means 4, when service element 2 can no longer eliminate an error itself. If the 
component in question can also no longer be repaired using the remote 
diagnosis of the service provider, then the service provider contacts the user of 
the distributed system, using communication means 4, in order to request that he 
or she visit a repair shop. Display 7 and/or communication means 4 is used for 
this. As an alternative, the audio playback of the car radio, which includes DAB 
receiver 6, can be used. 

The specification then discloses, on page 7, lines 10-19, performing a functional 
test, but refers to the testing as being performed by the local service element, and 
not by a remote means, thereby making it unclear to one having ordinary skill in the 
art whether this testing is considered to be the remote testing, specifically: 
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A method known for this is the checksum method. CRC (cyclical redundancy 
check) sums are calculated using code segments of the software, and are 
compared. In this manner, an incorrect code can be identified, and, if the 
remaining software of the service element has the independent capability, then 
the software can be repaired, e.g. by loading new software parts, so-called 
patches. In the case of serious software errors of service element 2, an 
emergency operation of service element 2 can ensure the correction. A functional 
test of the bus communication can be carried out using predefined signals, which 
are transmitted on the bus, and to which a certain response from the connected 
components is expected, this response being known to service element 2. This 
ensures that an error message of a subsystem is not lost due to a bus 
interruption. 

Finally, the specification, on page 7, line 28 to page 8, line 3 discusses testing 

with respect to the remote service provider, specifically: 

Service element 2 questions a service provider in certain time intervals, e.g. 
once a month, if new software versions are available for the individual 
components of the distributed system. If this is the case, the service element 
requests such a new software version, and then loads it using communication 
means 4. The new software version is tested for errors, using test vectors, and is 
then configured for the corresponding components. Such an upgrade is then the 
specific software, or also the manufacturer of the components. It can also be a 
service company, which takes over the distribution of the software and the 
maintenance tasks. 



However, this section does not remedy the lack of enablement of the claimed 
limitations because is discusses the testing as testing the new software version for 
errors. The claimed limitations in question require "performing an error diagnosis of 
software running on the other components" and "allowing a remote diagnosis of the 
other components of the distributed system to be carried out, wherein the remote 
diagnosis includes testing at least one of the other components", and therefore it is 
unclear to one having ordinary skill in the art whether the discussed testing of the 
new software version for errors is with reference to the claimed "performing an error 
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diagnosis of software running on the other components" or "remote. . .diagnosis of 
the other components". 

Therefore, while Appellant argues that support can be found for the limitations in 
question by turning to "the specification that recites 'service element 2 allows a 
service provider to carry out a remote diagnosis of the individual components, 
using communication means 4. This service provider can then test the individual 
components directly, using communication means 4 and service element 2.' 
Substitute Specification at page 5, lines 13-15 (emphasis added)", the Examiner 
asserts that because the specification on page 5, lines 17-23 only discusses the 
remote diagnosis with respect to the service provider, the specification on page 7, 
lines 10-19, discusses testing with respect to a local, not remote, device, and page 
7, line 28 to page 8, line 3 discusses testing a new software version for errors, that 
appears to be non-distinct from the claimed "processing device disposed in the 
motor vehicle and adapted to perform operations including the operations 
of:... performing an error diagnosis of software running on the other components", 
the specification does not sufficiently enable the invention as claimed in claim 1 1 . 

Additionally, the Examiner asserts that on page 3 of the Appeal Brief, Appellant 
presents a summary of independent claim 1 1 , as required per 37 CFR 
41.37(c)(1)(v): 

Claim 1 1 relates to a service element, e.g., element 2 of Fig. 1 , that belongs 
to a distributed system (e.g., Fig. 1) as a component. See, e.g., Substitute 
Specification, page 4, lines 4-5. The distributed system further includes other 
components (e.g., Fig. 1, elements 3-7) that are independent of one another and 
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interconnected by a bus (e.g., Fig. 1, element 1). See, e.g., id. at page 4, lines 5- 
7. The service element (Fig. 1 , element 2) includes a processing device for 
configuring the other components; maintaining the other components; performing 
an error diagnosis of software running on the other components and correcting 
any errors; allowing a remote diagnosis of the other components of the 
distributed system to be carried out, including testing at least one of the other 
components; and performing an emergency function. See, e.g., Fig. 4; Substitute 
Specification, page 1, lines 22-25. 



The Examiner asserts that in providing a concise explanation of the subject 
matter defined in independent claim 1 1 , per 37 CFR 41 .37(c)(1 )(v), Appellant 
indicates that the features of "a processing device for configuring the other 
components; maintaining the other components; performing an error diagnosis of 
software running on the other components and correcting any errors; allowing a 
remote diagnosis of the other components of the distributed system to be carried 
out, including testing at least one of the other components; and performing an 
emergency function" are supported by Figure 4 and page 1 , lines 22-25, which 
states: 

In contrast, the service element of the present invention and the distributed 
system of the present invention have the advantage that the service element is 
able to carry out configurations, upgrades, maintenance, and, if necessary, 
emergency functions on the components of the distributed system. 



The Examiner asserts that this section, in addition to the sections cited by the 
Examiner, fail to sufficiently enable one having ordinary skill in the art to make 
and/or use the claimed limitations of both "performing an error diagnosis of software 
running on the other components" and "allowing a remote diagnosis of the other 
components of the distributed system to be carried out, wherein the remote 
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diagnosis includes testing at least one of the other components" as required by 35 
U.S.C. 112, first paragraph. 



• With respect to the rejection of claim under 35 U.S.C. 112, first paragraph, as 
failing to comply with the written description requirement, Appellant argues: 

Claims 26 further recites "a processing device disposed in the motor vehicle 
and adapted to perform operations." Support for these features may be found in 
the Substitute Specification, e.g., at page 3, lines 30 to 33, which states "the 
component either being provided with its own hardware, i.e. its own processor, or 
running on an already existing processor, in parallel with other software, if this 
processor allows another component to do this." 

Claim 26 further recites "automatically, and at predefined intervals, performing 
an error diagnosis of software running on the other components." Support for 
these features may be found in the Substitute Specification, e.g., at page 7, line 
6, which states that "[i]n regular intervals, service element 2 checks the 
components." Also, at page 3, lines 25 to 28, the Substitute Specification states 
"the present invention provides for a service element being used, which 
automatically configures components, performs maintenance tasks, and, in 
particular, updates individual components with new software versions, and, if 
necessary, automatically executes an emergency function as well, without the 
user having to intervene." 

Claim 26 further recites "for each of a first subset of errors diagnosed in the 
error diagnosis step, repair the error, " and for each of a second subset of errors 
diagnosed in the error diagnosing step, contact a provider and allow the provider 
to responsively remotely repair the error." Support for these features may be 
found in the Substitute Specification, e.g., at page 5, lines 17 and 18, which 
states that "[s]ervice element 2 also contacts the service provider, using 
communication element 4, when service element 2 can no longer eliminate an 
error itself." Additionally, page 5, lines 13 to 15, states that "service element 2 
allows a service provider to carry out a remote diagnosis of the individual 
components, using communication element 4. This service provider can then test 
the individual components directly, using communication element 4 and service 
element 2." Additionally, page 5, lines 19 and 20 (emphasis added), states that "if 
the component in question can also no longer be repaired using the remote 
diagnosis of the service provider, then the service provider contacts the user of 
the distributed system." The above provided sections of the specification clearly 
describe errors the component can repair/fix/eliminate by itself, and a second 
group of errors that cause a provider to be contacted for repair. 
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It is clear that Appellants had possession of each element of claim 26 at the 
time of filing. Further, as each cited reference deals with the service element, 
remote provider, and the interrelationship of the two, it is clear from the cited 
portions of the specification that Appellants had possession of this very 
combination of features now found in claim 26. 



The Examiner asserts that claim 26, as amended/presented, requires, "a 
processing device disposed in the motor vehicle and adapted to perform operations 
including the operations of: automatically, and at predefined intervals, performing an 
error diagnosis of software running on the other components; for each of a first 
subset of errors diagnosed in the error diagnosis step, repair the error; and for each 
of a second subset of errors diagnosed in the error diagnosing step, contact a 
provider and allow the provider to responsively remotely repair the error." 

Appellant argues that support for the features of "for each of a first subset of 
errors diagnosed in the error diagnosis step, repair the error; and for each of a 
second subset of errors diagnosed in the error diagnosing step, contact a provider 
and allow the provider to responsively remotely repair the error" may be found in the 
specification at page 5, lines 17 and 18, page 5, lines 13-15, and page 5, lines 19 
and 20. 

Page 5, lines 13-23 of the specification states: 

In addition, service element 2 allows a service provider to carry out a remote 
diagnosis of the individual components, using communication element 4. This 
service provider can then test the individual components directly, using 
communication element 4 and service element 2. 

Service element 2 also contacts the service provider, using communication 
element 4, when service element 2 can no longer eliminate an error itself. If the 
component in question can also no longer be repaired using the remote 
diagnosis of the service provider, then the service provider contacts the user of 
the distributed system, using communication element 4, in order to request that 
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he or she visit a repair shop. Display 7 and/or communication element 4 is used 
for this. As an alternative, the audio playback of the car radio, which includes 
DAB receiver 6, can be used. 

The Examiner asserts that this section does suggest that the service element 
(i.e. processing device disposed in the motor vehicle) can both repair errors and, if 
an error is obtained that cannot be repaired, contact a provider and allow the 
provider to responsively remotely repair the error by disclosing "[s]ervice element 2 
also contacts the service provider, using communication means 4, when service 
element 2 can no longer eliminate an error itself. 

This section, however, also explicitly indicates that the "service element 2 allows 
a service provider to carry out a remote diagnosis of the individual components, 
using communication means 4" and "[t]his service provider can then test the 
individual components directly, using communication means 4 and service element 
2". This section, therefore, indicates that it is the service provider that carries out a 
remote diagnosis and does not support 1) local error diagnosis by the on-vehicle 
processing device or 2) that the diagnosis is an error diagnosis of software, as 
required by claim 26. 

With respect to error diagnosis of software, the specification indicates on page 7, 
line 6 to page 8, line 3: 

In regular intervals, service element 2 checks the components, which are 
connected to bus 1 , and to which service element 2 also belongs. Therefore, a 
self-diagnosis is also carried out. This self-diagnosis, which is performed by 
software, is carried out using a suitable method. 

A method known for this is the checksum method. CRC (cyclical redundancy 
check) sums are calculated using code segments of the software, and are 
compared. In this manner, an incorrect code can be identified, and, if the 
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remaining software of the service element has the independent capability, then 
the software can be repaired, e.g. by loading new software parts, so-called 
patches. In the case of serious software errors of service element 2, an 
emergency operation of service element 2 can ensure the correction. A functional 
test of the bus communication can be carried out using predefined signals, which 
are transmitted on the bus, and to which a certain response from the connected 
components is expected, this response being known to service element 2. This 
ensures that an error message of a subsystem is not lost due to a bus 
interruption. 

If service element 2 detects an error, then service element 2 contacts a 
service provider using communication means 4, in order to load corrected 
software and consequently configure the specific components of the distributed 
system. But if there is a hardware error, then service element 2 initially sends a 
message to a service provider, who then contacts the user, so that the 
components in question are replaced or repaired. This error diagnosis is 
conducted in certain time intervals, e.g. once a day or every week or once a 
month. 

Service element 2 questions a service provider in certain time intervals, e.g. 
once a month, if new soft-ware versions are available for the individual 
components of the distributed system. If this is the case, the service element 
requests such a new software version, and then loads it using communication 
means 4. The new software version is tested for errors, using test vectors, and is 
then configured for the corresponding components. Such an upgrade is then 
automatically carried out by the visitor alone. A service provider can be the 
manufacturer of the specific software, or also the manufacturer of the 
components. It can also be a service company, which takes over the distribution 
of the software and the maintenance tasks. 



The Examiner asserts that this section does support the claimed limitations of "a 
processing device disposed in the motor vehicle and adapted to perform operations 
including the operations of: automatically, and at predefined intervals, performing an 
error diagnosis of software running on the other components" by providing a service 
element that periodically performs a CRC. 

With respect to error correction (i.e. repair), this section, however, indicates that 
"the software can be repaired, e.g. by loading new software parts, so-called patches" 
wherein such repair is disclosed as "[i]f service element 2 detects an error, then 



Application/Control Number: 09/913,992 Page 36 

Art Unit: 2857 

service element 2 contacts a service provider using communication means 4, in 
order to load corrected software and consequently configure the specific 
components of the distributed system" or "if there is a hardware error, then service 
element 2 initially sends a message to a service provider, who then contacts the 
user, so that the components in question are replaced or repaired." This section, 
therefore, indicates that if a first subset of errors is diagnosed, the service element 
contacts a service provider to repair the error and if a second subset of errors is 
diagnosed, the service provider is also contacted, but in this instance a user is 
further contacted so that the components in question can be replaced or repaired. 

This does not support a limitation of "a processing device disposed in the motor 
vehicle and adapted to perform operations including the operations of... for each of a 
first subset of errors diagnosed in the error diagnosis step, repair the error; and for 
each of a second subset of errors diagnosed in the error diagnosing step, contact a 
provider and allow the provider to responsively remotely repair the error" because for 
the first subset of errors, it is still the service provider that is remotely contacted to 
upload corrected software to repair the error and, for the second subset of errors, a 
user is contacted to manually repair the error locally rather than performing such 
repair by the provider remotely. 

Additionally, this second subset of errors corresponds to a hardware error and, 
therefore, does not properly support determining a second subset of errors based on 
"performing an error diagnosis of software running on the other components". 
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For these reasons, the Examiner asserts that the specification does not 
adequately support "a processing device disposed in the motor vehicle and adapted 
to perform operations including the operations of: automatically, and at predefined 
intervals, performing an error diagnosis of software running on the other 
components; for each of a first subset of errors diagnosed in the error diagnosis 
step, repair the error; and for each of a second subset of errors diagnosed in the 
error diagnosing step, contact a provider and allow the provider to responsively 
remotely repair the error" and, as such, claim 26 contains subject matter which was 
not described in the specification in such a way as to reasonably convey to one 
skilled in the relevant art that the inventor(s), at the time the application was filed, 
had possession of the claimed invention. 



• With respect to claims 11, 12, 14, 1 7-20 and 23, as may best be understood, 
under 35 U.S.C. 103(a) as being unpatentable over U.S. Patent No. 6,370,449 to 
Razavi et al. in view of U.S. Patent No. 6,51 2,968 to de Bellefeuille et al., Appellant 
argues: 

Claims 1 1 and 19, as well as their dependent claims, should be allowed 
because neither Razavi nor de Bellefuille discloses the feature of "performing an 
emergency function." The Examiner refers to col. 1, lines 41-46 and col. 7, lines 
54-63 of Razavi as assertedly disclosing this feature. However, col. 1 , lines 41- 
46, the "background" section of Razavi that discusses traditional automobile 
design, states: "designers may also incorporate into the vehicle the delivery of 
services that may assist the driver, thereby reducing the driver's workload and 
anxiety level. Such services may include providing computerized maps, 
navigation aids and emergency assistance signaling." First, this does not 
disclose "a processing device disposed in the motor vehicle and adapted to 
perform operations including the operations of:.., performing an emergency 
function." Since this section discusses "traditional" automobile designs, and does 
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not further elaborate on "emergency function," the disclosure is likely referring to 
simple hazard signal lights, which does not require any processing device 
adapted to perform operations including performance of an emergency function. 
In any event, it does not identically disclose "a processing device.., to perform.., 
an emergency function." Second, even if one assumed that this did disclose 
"performing an emergency function," it does not form any part of any 
embodiment of Razavi. In this hypothetical case, it would actually teach away 
from the combination, because while Razavi discusses emergency assistance 
signaling in the background section, Razavi, nevertheless, omits any such 
feature from the embodiments of the Razavi disclosure. 

The Examiner argues that this "refers to emergency assistance signaling as 
one particular delivery of services to the user which are described throughout the 
disclosure as network-based services (see, for example, column 5, lines 9-35) 
and are also described as being performed by a processing device, along with a 
map service, in column 7, lines 54-63." However, this characterization is simply 
incorrect. It may be true that col. 5, lines 9 to 35 and col. 7, lines 54-63 discuss 
network based services and services provided by a processor, but the services 
discussed in these sections have absolutely nothing to do with "performing an 
emergency function," and merely discloses text-to- speech and computerized 
maps. It seems that the Examiner is arguing that since the background section of 
Razavi discloses a prior art service of "emergency assistance signaling," and 
since embodiments of Razavi disclose computerized services such as text- to- 
speech, that Razavi discloses a "processing device.., to perform.., an emergency 
function." This assertion is not logically sustainable. Razavi may disclose prior art 
"emergency assistance signaling," and further disclose other computerized 
services, but this simply does not disclose the feature of a "processing device.., 
to perform.., an emergency function." 



The Examiner asserts that Appellant's arguments are not considered to be 
persuasive for the following reasons: 

The Examiner first asserts that Razavi discloses an easily-upgradeable vehicle 
component architecture comprising a processing device operable to interact with, 
and control, processor-controlled components that provide services: 

This mechanism may also be used to personalize the operation of the 
automobile, adjusting seat positions, radio stations and the like according to the 
preferences of different drivers. The extent to which this mechanism controls the 
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various functions of the automobile depends, of course, upon the coupling of the 
related automobile components to the in-car sub-network, (column 7, lines 40-46) 

As indicated above, compute platform 22 is at the center of in-car sub- 
network 20. In one embodiment, compute platform 22 is a Java platform. (Java 
is a trademark of Sun Microsystems, Inc.) In other words, compute platform 22 
uses the Java programming language to provide an environment in which Java 
applications can be executed. The use of a Java environment in compute 
platform 22 allows the software that will be executed on the compute platform to 
be hardware independent, (column 8, lines 21-29) 

In other embodiments, similar software applications and monitors can be 
used to generate graphics for other equipment such as console displays, radio 
controls, air conditioning controls and the like. Other embodiments may also 
utilize independent processors and memories to generate graphics for the 
monitors rather than having the graphics generated by an application executing 
on the server, (column 1 1 , lines 14-20) 



The Examiner then asserts that Razavi explicitly discloses the well-known prior 
art services of "computerized maps, navigation aids and emergency assistance 
signaling", specifically: 



The designers may also incorporate into the vehicle the delivery of services 
that may assist the driver, thereby reducing the driver's workload and anxiety 
level. Such services may include providing computerized maps, navigation aids 
and emergency assistance signaling, (column 1, lines 41-46) 



The Examiner also asserts that Razavi explicitly discloses that the entire purpose 
Razavi is to improve upon the prior art system by providing services to a user as part 
of the easily-upgradeable vehicle component architecture: 



While it may be desirable to upgrade the components of automobiles, they 
are often difficult, if not impossible, to upgrade. The components typically have 
unique physical and functional characteristics, including their size, shape and 
interface to the automobile, which prevent them from being replaced with similar, 
but not identical parts. Further, the replacement of the components can be very 
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labor-intensive, and it is not unusual for the cost of the labor to install the 
components to be on the same order as the cost of the components themselves. 
There is therefore no practical way in the prior art for an automobile which 
is already in production to be upgraded to maintain state-of-the-art 
components and/or functionality, (emphasis added- column 1 , line 61 to 
column 2, line 6) 

IP (Internet Protocol) is a protocol which is typically used in conjunction with 
TCP (Transport Control Protocol) as a protocol suite for passing data from 
applications to networks and then from the networks to other applications. The 
IP portion of the protocol suite is used in transporting packets from the 
transmitting device to the receiving device. IP addresses are, of course, the 
means by which the packets are directed to the target device. Because IP 
addresses are well-known in the data-processing arts, they will not be explained 
in further detail here. It is sufficient to note that IP addressing allows data to be 
directed to devices which are not part of a predetermined, hard-wired design. 
"Object terminology," as used in this disclosure, refers to software language 
which handles devices in an object-oriented manner. That is, the devices and 
their functions can be used in a manner which is not dependent upon the specific 
implementation of the device, but instead upon the type and functions of the 
device. For instance, as will be explained below in regard to Jini software, a 
device which joins a network may register its services with a lookup server so 
that other devices which need these services can request them without regard to 
the specific device that provides them. In contrast, prior art on-board 
diagnostic buses have specific, predetermined devices which provide 
specific, predetermined services and which transmit/receive data over a 
specific, predetermined path. By using IP addressing and object terminology 
to provide communication between devices on the network, the invention 
eliminates the constraints which are inherent in bus systems. (Communication, 
as used here, includes data transfer and any other interaction between the 
devices.) (emphasis added- column 3, line 61 to column 4, line 24) 

The goals of the system can be grouped into three broad categories: 
hardware independence; service delivery; and software upgradability. The 
hardware independence of the system is related to the interchangeability of the 
components of the automobile's sub-network. If, for example, the sub-network 
includes a graphical display, this display should be replaceable with several 
different displays, each having unique characteristics. The several displays only 
need to be able to interface with the sub-network in order to be exchanged. The 
goal of service delivery relates to the ability to provide new and different services 
to the vehicle through the sub-network. Although automobiles in the prior art 
may provide one or two services to the driver, e.g. driver assistance via 
automatic telephone communications, the equipment for providing these 
services are dedicated to their respective services and cannot provide 
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distinctly different services. The present system, on the other hand, allows 
new components or new software to be added to the automobile sub- 
network and thereby enables new services to be provided to the driver. 

Finally, software upgradeability relates to the ease with which software systems 
in the automobile may be upgraded via the automobile sub-network. Rather than 
manually replacing memory modules or CDs (e.g. containing map data,) the 
automobile sub-network enables the downloading of new applications or data, as 
well as the uploading of vehicle diagnostic data or other information, through the 
network communication devices, (emphasis added - column 5, lines 9-35) 

As indicated above, the configuration of the vehicle components as network 
devices on an in-car sub-network simplifies installation and removal of the 
devices, hence re-configuration of the vehicle. This system thereby makes it 
possible to remove outdated components and replace them with new 
components, even though the new components may have different features or 
require different data or other signals from the vehicle or its components. 
Similarly, components which execute associated software, display data or 
provide services can be upgraded by downloading new software, data or 
services ("upgrade data") to the components through the in-car sub-network. 
This software may be quickly and easily retrieved from sources external to the in- 
car sub-network, such as web pages or LANs which can be accessed through 
the communication devices on the in-car sub-network. The software can be 
retrieved by one device (e.g., a wireless modem,) conveyed through the network 
and installed in a second device (e.g., a GPS locator) as easily as downloading a 
web page. The system thereby provides a great deal of flexibility in the hardware 
and software configurations of the vehicle. In contrast, prior art systems for 
providing in-car services are tightly coupled to the car manufacturer's 
choice of hardware and operating system. Changes to the hardware 
reguire substantial time, labor and expense. Changes to the software 
require the original software supplier to provide modified code. The use of 
Personal Java in the in-car sub-network provides platform independence and 
also eliminates a substantial portion of the labor, time and costs involved in 
replacing and upgrading the vehicle's components and functionality, (emphasis 
added - column 13, line 46 to column 14, line 8) 



The Examiner also asserts that Razavi explicitly discloses that these services 
being provided to a user as part of the easily-upgradeable vehicle component 
architecture include the well-known prior art "computerized maps" and "navigation 



aids": 
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The designers may also incorporate into the vehicle the delivery of services 
that may assist the driver, thereby reducing the driver's workload and anxiety 
level. Such services may include providing computerized maps, navigation aids 
and emergency assistance signaling, (column 1, lines 41-46) 



In-car sub-network 20 can also communicate with external systems such as 
global positioning systems (GPS) and traffic information systems. A GPS 
receiver 30 is coupled to in-car sub-network 20 for providing automobile location 
information. GPS receiver 30 is capable of collecting information from GPS 
satellites to determine the position of the automobile. This information is 
converted to a format appropriate for other uses within the in-car sub-network, 
such as map retrieval for the area around the automobile. A Cue traffic 
information receiver 31 is also coupled to in-car sub-network 20. Receiver 31 
obtains traffic information (e.g., information on traffic jams) which can be used, 
for example, by navigation systems running on in-car sub-network 20 to 
determine the best route for the automobile to take. Both GPS receiver 30 and 
traffic information receiver 31 are connected to compute platform 22 by RS-232 
connectors, (column 6, line 58 to column 7, line 7). 

For example, the driver may simply recite the appropriate command for 
determining the location of the automobile, whereupon compute platform 22 
might query GPS receiver 30 for location information, then retrieve a map from a 
web site and display the map to the driver. Compute platform 22 may also 
include a text-to-speech engine for use in delivering information to the driver. For 
example, the in-car sub-network may retrieve the driver's email or other 
documents, convert the text to speech and then "read" the document to the 
driver, (column 7, lines 54-63). 



Therefore, the Examiner asserts that, given the cited sections above, one having 
ordinary skill in the art would clearly recognize that the invention of Razavi discloses 
a system that replaces the prior art services, including the emergency assistance 
signaling, with the easily-upgradeable, processor-controlled components. 
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Further, the Examiner asserts that the claims do not specify what constitutes the 
"emergency function." Therefore, while the Examiner does maintain that the 
invention of Razavi discloses a processing device adapted to perform operations 
including the operation of performing emergency assistance signaling, the Examiner 
also asserts that Razavi discloses a processing device adapted to perform other 
emergency functions including security functions and/or traffic avoidance functions: 



One embodiment of the invention comprises a vehicle which has a network 
installed therein. The network includes one or more devices which are 
addressable using IP addresses or object terminology. The devices may include 
various servers and clients, such as microphones, cameras, GPS receivers, 
interfaces to on-board diagnostic systems, communication devices, displays, CD 
players, radios, speakers, security devices and LANs (local are networks) to 
name only a few. Devices may easily be connected or disconnected to upgrade 
or reconfigure the vehicle's systems, and software and services can easily be 
provided to the various devices through the network. The network can enable 
the interaction of various network devices to increase the capabilities or utility of 
devices which may otherwise be limited. The system therefore provides an easy 
and inexpensive means to improve or otherwise modify the functionality of the 
vehicle, (column 2, lines 18-34) 

In-car sub-network 20 can also communicate with external systems such as 
global positioning systems (GPS) and traffic information systems. A GPS 
receiver 30 is coupled to in-car sub-network 20 for providing automobile location 
information. GPS receiver 30 is capable of collecting information from GPS 
satellites to determine the position of the automobile. This information is 
converted to a format appropriate for other uses within the in-car sub-network, 
such as map retrieval for the area around the automobile. A Cue traffic 
information receiver 31 is also coupled to in-car sub-network 20. Receiver 31 
obtains traffic information (e.g., information on traffic jams) which can be used, 
for example, by navigation systems running on in-car sub-network 20 to 
determine the best route for the automobile to take. Both GPS receiver 30 and 
traffic information receiver 31 are connected to compute platform 22 by RS-232 
connectors, (column 6, line 58 to column 7, line 7). 



• Appellant argues: 
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Independent of the above, claims 1 1 and 1 9, as well as their dependent 
claims, should be allowed because neither Razavi nor de Bellefuille disclose the 
feature of "a processing device disposed in the motor vehicle and adapted to 
perform operations including the operations of: configuring the other 
components; maintaining the other components;..." The Examiner asserts that 
Razavi discloses a service element that maintains other components and de 
Bellefuille discloses that maintenance may include performing an error diagnosis. 
Specifically, the Examiner asserts that col. 6, lines 9-17 and col. 8, lines 50-67 of 
Razavi disclose a service element that maintains other components. The 
"Examiner asserts that Razavi discloses a service element that is the central 
component of the in-car sub-network that handles the processing and 
programming functions of the other components on the network." Final Office 
Action at page 26. First, this characterization of these sections of Razavi makes 
no mention of "maintaining," just as the sections themselves makes no mention 
of "maintaining." Additionally, even if "processing and programming" identically 
disclosed "maintaining," these sections of Razavi simply do not disclose 
"processing and programming." Col. 6, lines 9-17 merely states that all devices 
are either directly or indirectly plugged into the compute platform. This neither 
states nor implies that the compute platform "handles the processing and 
programming functions of the other components." Further, col. 8, lines 50-67 
merely identifies JVM as the execution environment for the compute platform. 
This may disclose that any application running on the compute platform will run in 
Java, but does not disclose the compute platform processing, programming, or 
maintaining the connected devices. 



The Examiner first asserts that in response to a Final Office Action mailed July 
27, 2007, wherein claims were rejected as failing to comply with the enablement 
requirement "because the specification fails to provide adequate disclosure to one 
having ordinary skill as to the manner for performing upgrading and maintaining" due 
to the specification suggesting that "the updating of individual components with new 
software versions is a particular manner of carrying out maintenance tasks, thereby 
not supporting the separate operations of 'upgrading the other components' and 
'maintaining the other components', Appellant argued in the response filed January 
15, 2008: 
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Claims 11, 12, 14 and 16-25 stand rejected under 35 U.S.C. §112, 1J1 as 
failing to comply with the enablement requirement. In particular, the Examiner 
believes that the operations of "upgrading" and "maintaining" should not be 
recited as separate steps. In particular, the Examiner believes that "upgrading of 
individual components with new software versions is a particular manner of 
carrying out maintenance tasks." Accordingly, Applicants have amended claims 
1 1 and 19 to delete the separate reference to "upgrading." Claims 24 and 25 
have been canceled, without prejudice (Applicant's arguments, January 15, 
2008, page 4). 



Therefore, while Appellant argues that the cited "sections of Razavi makes no 
mention of 'maintaining,'", the Examiner asserts that Appellant has already admitted 
that upgrading and maintaining are equivalent. 



The Examiner then asserts that Razavi discloses a service element that belongs 
to a distributed system in a motor vehicle as a component (column 6, lines 10-18), 
the distributed system further including other components that are independent of 
one another (column 3, lines 30-33) and interconnected by a bus (column 4, lines 
40-47), the service element comprising a processing device disposed in the motor 
vehicle (column 8, lines 21-49) and adapted to perform operations including the 
operations of configuring the other components (column 7, lines 40-46, column 8, 
lines 21-29, and column 1 1 , lines 1 4-20), maintaining the other components (column 
13, lines 53-61 and column 15, lines 6-13)..., by disclosing a computer platform "22" 
that configures the setting of other components, through a Java™ dashboard, and 
upgrades the data/software of other components, specifically: 
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This mechanism may also be used to personalize the operation of the 
automobile, adjusting seat positions, radio stations and the like according to the 
preferences of different drivers. The extent to which this mechanism controls the 
various functions of the automobile depends, of course, upon the coupling of the 
related automobile components to the in-car sub-network, (column 7, lines 40-46) 

As indicated above, compute platform 22 is at the center of in-car sub- 
network 20. In one embodiment, compute platform 22 is a Java platform. (Java 
is a trademark of Sun Microsystems, Inc.) In other words, compute platform 22 
uses the Java programming language to provide an environment in which Java 
applications can be executed. The use of a Java environment in compute 
platform 22 allows the software that will be executed on the compute platform to 
be hardware independent, (column 8, lines 21-29) 

In other embodiments, similar software applications and monitors can be 
used to generate graphics for other equipment such as console displays, radio 
controls, air conditioning controls and the like. Other embodiments may also 
utilize independent processors and memories to generate graphics for the 
monitors rather than having the graphics generated by an application executing 
on the server, (column 1 1 , lines 14-20) 



Similarly, components which execute associated software, display data or 
provide services can be upgraded by downloading new software, data or 
services ("upgrade data") to the components through the in-car sub-network. 
This software may be quickly and easily retrieved from sources external to the in- 
car sub-network, such as web pages or LANs which can be accessed through 
the communication devices on the in-car sub-network. The software can be 
retrieved by one device (e.g., a wireless modem,) conveyed through the network 
and installed in a second device (e.g., a GPS locator) as easily as downloading a 
web page, (column 13, lines 53-61) 

Once the connection is established, the in-car sub-network and LAN can 
function as a single network. The service station may be configured to request 
the service records of the vehicle so that any necessary service may be 
performed. If a software maintenance update is required by one of the 
components in the vehicle, a server on the LAN may automatically download this 
information to the appropriate component, (column 15, lines 6-13) 



• Appellant argues: 

Nowhere in these two sections or any other section of Razavi is "a processing 
device disposed in the motor vehicle and adapted to perform operations including 
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the operations of: configuring the other components; maintaining the other 
components;..." disclosed. For example, at Razavi, col. 2, lines 14 to 15, "re- 
configuring and upgrading of the vehicle" is disclosed. However, this discloses 
upgrading the overall vehicle by interchanging parts, and not upgrading (or 
otherwise maintaining) those parts. Razavi, at col. 3, lines 33-37, likewise 
discloses upgrading the vehicle by exchanging devices, and not upgrading (or 
otherwise maintaining) the devices. Razavi, at col. 5, lines 26-29, discloses that 
the system "allows new components or new software to be added to the 
automobile sub-network and thereby enables new services to be provided to the 
driver." However, this again does not disclose "a processing device disposed in 
the motor vehicle and adapted to perform operations including the operations of: 
configuring the other components; maintaining the other components;..." "New 
components" again refers to the exchange of devices connected to the network, 
and "new software" may refer to any number of things, and does not disclose any 
particular device "maintaining" other components with "new software." For 
example, Razavi, at col. 10, lines 26-31, discloses that "server 53 allows the 
services which are provided to be upgraded or otherwise modified, whereas 
services provided by many embedded servers are 'hard wired' into them, thereby 
limiting their capabilities and their upgradeability." Here, as in the last cited 
section of Razavi, the "upgrading" is being performed on the central component, 
and not on the "other components." 

Of the many references in Razavi to upgrading, replacing, re-configuring, or 
otherwise performing a task (e.g., the four examples provided above); only one 
reference is made to "upgrading" an existing connected device (i.e., other than 
the central device). Razavi, at col. 13, lines 54-64, states that "components which 
execute associated software, display data or provide services can be upgraded 
by downloading new software, data or services ('upgrade data') to the 
components through the in-car sub-network... The software can be retrieved by 
one device (e.g., a wireless modem,) conveyed through the network and installed 
in a second device (e.g., a GPS locator)..." However, there is absolutely no 
mention of what device does the "installing] in a second device." The compute 
platform 22 (i.e., the alleged processing device of claims 11 and 19) is not 
mentioned anywhere in this section. Further, if it is argued that earlier disclosure 
indicates that the modem and GPS must both be connected to the compute 
platform, Razavi still fails to disclose the present features for at least two 
reasons. First, Razavi states that devices are connected to the compute platform 
directly or via a network (e.g., Ethernet). Therefore, the GPS may be directly 
connected to the modem, indirectly connected to the compute platform via a 
network, and perform this "upgrade" directly with the modem (i.e., with no 
involvement from the compute platform). Second, even if one assumes all 
devices are directly connected to the compute platform, Razavi only refer to that 
which is "conveyed through the network." Conveying data is the function of a 
switch or router, and does not constitute "maintaining" or "configuring" the device 
to which data is merely conveyed. 



Application/Control Number: 09/913,992 
Art Unit: 2857 



Page 48 



As explained above, in great detail, though several sections of Razavi refers 
to upgrading, absolutely no section discloses "a processing device disposed in 
the motor vehicle and adapted to perform operations including the operations of: 
configuring the other components; maintaining the other components;..." 



While Appellant argues that "the software can be retrieved by one device (e.g., a 

wireless modem,) conveyed through the network and installed in a second device 

(e.g., a GPS locator)..." but "there is absolutely no mention of what device does the 

"installing] in a second device", the Examiner asserts that Razavi is explicit that it is 

the service element that is the central component "22" of the in-car sub-network and 

that handles the processing and programming functions of the other components on 

the network, specifically: 

Referring to FIG. 2, a more detailed block diagram of in-car sub-network 20 is 
shown. FIG. 2 illustrates some of the components that may be coupled to the 
network. In-car sub-network is built around an on-board compute platform 22. 
Compute platform 22 consists of a SparcStation UPN server (a prototype Sparc 
5-based system.) All of the components of the in-car sub-network are either 
directly plugged into the compute platform or coupled to do it via an ethernet 
connection, (column 6, lines 9-17) 

As indicated above, compute platform 22 is at the center of in-car sub- 
network 20. In one embodiment, compute platform 22 is a Java platform. (Java 
is a trademark of Sun Microsystems, Inc.) In other words, compute platform 22 
uses the Java programming language to provide an environment in which Java 
applications can be executed. The use of a Java environment in compute 
platform 22 allows the software that will be executed on the compute platform to 
be hardware independent, (column 8, lines 21-29) 
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The organization of the operating environment of compute platform 22 is 
shown in FIG. 3. At the lowest level of the diagram shown in FIG. 3 is hardware 
41 . Hardware 41 comprises the physical server (or other processor) on which 
the software is executed. Hardware 41 may comprise a SparcStation as in the 
above-described embodiment, or any other suitable computer, such as a 
StrongARM, PowerPC, Intel, MIPS or Mitsubishi system. Hardware 41 executes 
an operating system 42 which provides the basic functionality of the compute 
platform. The particular operating system selected to be used with hardware 41 
will depend upon the type of processor upon which hardware 41 is built, and may 
also depend upon the network's requirements, if more than one operating system 
is available for the chosen hardware. A few of the operating systems which may 
be available are VxWorks, PSOS, OS9, Chorus and Linux. Operating system 42 
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supports Transport Control Protocol/Internet Protocol (TCP/IP) 43. Each of the 
devices connected to the in-car sub-network can therefore be addressable as a 
network device, (column 8, lines 30-49) 



Compute platform 22 runs Java virtual machine 44. Java virtual machine 44 
is a software application that executes in the environment of the native operating 
system and provides a common environment for applications written in the Java 
programming language. In other words, Java virtual machine 44 provides a layer 
of abstraction between an operating system and an executable program, 
essentially providing a Java-to-operating system interface so that programs 
written in the Java programming language can be executed on a platform running 
an operating system which would not otherwise support execution of the 
program. Because Java virtual machines exist for many different compute 
platforms, the same Java language program can be executed on each of these 
different platforms. In this manner, the hardware/operating system portion of the 
system is made a commodity. As a result, the remainder of the system is no 
longer tied to the original hardware, the original operating system, or the original 
supplier thereof (column 8, lines 50-67). 



The Examiner also asserts that Razavi discloses that when 
maintenance/upgrading is being performed, the service element is used to perform 
such maintenance by receiving maintenance information from the communication 
devices that is then transmitted through the service element for updating the 
destination component, specifically: 



As indicated above, the configuration of the vehicle components as network 
devices on an in-car sub-network simplifies installation and removal of the 
devices, hence re-configuration of the vehicle. This system thereby makes it 
possible to remove outdated components and replace them with new 
components, even though the new components may have different features or 
require different data or other signals from the vehicle or its components. 
Similarly, components which execute associated software, display data or 
provide services can be upgraded by downloading new software, data or 
services ("upgrade data") to the components through the in-car sub-network. 
This software may be quickly and easily retrieved from sources external to the in- 
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car sub-network, such as web pages or LANs which can be accessed through 
the communication devices on the in-car sub-network. The software can be 
retrieved by one device (e.g., a wireless modem,) conveyed through the network 
and installed in a second device (e.g., a GPS locator) as easily as downloading a 
web page. The system thereby provides a great deal of flexibility in the hardware 
and software configurations of the vehicle. In contrast, prior art systems for 
providing in-car services are tightly coupled to the car manufacturer's choice of 
hardware and operating system. Changes to the hardware require substantial 
time, labor and expense. Changes to the software require the original software 
supplier to provide modified code. The use of Personal Java in the in-car sub- 
network provides platform independence and also eliminates a substantial 
portion of the labor, time and costs involved in replacing and upgrading the 
vehicle's components and functionality, (column 13, line 46 to column 14, line 8). 



In another scenario, a service station may have a wireless LAN so that a 
vehicle equipped with a network and wireless communication device can 
establish a connection with the LAN as the vehicle pulls into the station. Once 
the connection is established, the in-car sub-network and LAN can function as a 
single network. The service station may be configured to request the service 
records of the vehicle so that any necessary service may be performed. If a 
software maintenance update is required by one of the components in the 
vehicle, a server on the LAN may automatically download this information to the 
appropriate component. Alternately, the user of the vehicle may request 
information or services. For example, the user may request that music (e.g., in 
MP3 format) or videos (e.g., in MPEG-2 format) be downloaded for the 
passengers' entertainment. The user may also have information he or she 
wishes to have printed, in which case the information could be transmitted to a 
printer on the service station's LAN, where it could be picked up by the user, 
(column 15, lines 3-21) 



The Examiner further asserts that Razavi discloses that when the "other" 
components are being configured, the service element is used to perform such 
configuration by configuration the other devices through a virtual dashboard: 



This mechanism may also be used to personalize the operation of the 
automobile, adjusting seat positions, radio stations and the like according to the 
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preferences of different drivers. The extent to which this mechanism controls the 
various functions of the automobile depends, of course, upon the coupling of the 
related automobile components to the in-car sub-network, (column 7, lines 40-46) 

As indicated above, compute platform 22 is at the center of in-car sub- 
network 20. In one embodiment, compute platform 22 is a Java platform. (Java 
is a trademark of Sun Microsystems, Inc.) In other words, compute platform 22 
uses the Java programming language to provide an environment in which Java 
applications can be executed. The use of a Java environment in compute 
platform 22 allows the software that will be executed on the compute platform to 
be hardware independent, (column 8, lines 21-29) 

In other embodiments, similar software applications and monitors can be 
used to generate graphics for other equipment such as console displays, radio 
controls, air conditioning controls and the like. Other embodiments may also 
utilize independent processors and memories to generate graphics for the 
monitors rather than having the graphics generated by an application executing 
on the server, (column 1 1 , lines 14-20) 



• With respect to the rejection of claim 16, as may best be understood, under 35 

U.S.C. 103(a) as being unpatentable over Razavi et al. in view de Bellefeuille and 

further in view of U.S. Patent No. 6,330,499 to Chou et al., Appellant argues: 

Claim 16 depends from allowable claim 1 1 and is therefore allowable for at 
least the same reasons as claim 1 1 , since Chou does not correct the critical 
deficiencies of the combination of Razavi and de Bellefeuille noted above in 
support of the patentability of claim 1 1 . 



The Examiner maintains the rejection of claim 11 for the reasons provided above 
and, as such, Appellant's argument with respect to claim 16 is not considered to be 
persuasive. 
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• With respect to the rejection of claim 21 , as may best be understood, under 35 

U.S.C. 103(a) as being unpatentable over Razavi et al. in view de Bellefeuille and 

further in view of U.S. Patent No. 5,465,207 to Boatwright et al., Appellant argues: 

Claim 21 depends from allowable claim 1 1 and is therefore allowable for at 
least the same reasons as claim 1 1 , since Boatwright does not cure the critical 
deficiencies of Razavi and de Bellefeuille noted above in support of the 
patentability of claim 1 1 . 

The Examiner maintains the rejection of claim 11 for the reasons provided above 
and, as such, Appellant's argument with respect to claim 21 is not considered to be 
persuasive. 

• With respect to the rejection of claim 22, as may best be understood, under 35 

U.S.C. 103(a) as being unpatentable over Razavi et al. in view de Bellefeuille and 

further in view of U.S. Patent No. 5,964,813 to Ishii et al., Appellant argues: 

Claim 22 depends from allowable claim 1 1 and is therefore allowable for at 
least the same reasons as claim 1 1 , since Ishii does not cure the critical 
deficiencies of Razavi and de Bellefeuille noted above in support of the 
patentability of claim 1 1 . 

The Examiner maintains the rejection of claim 11 for the reasons provided above 
and, as such, Appellant's argument with respect to claim 22 is not considered to be 
persuasive. 

• With respect to the rejection of claim 26, as may best be understood, under 35 
U.S.C. 103(a) as being unpatentable over Razavi et al. in view de Bellefeuille and 
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Chou et al. and further in view of U.S. Patent No. 5,964,813 to Ishii et al., Appellant 
argues: 

Claim 26 includes subject matter analogous to that discussed above in 
support of the patentability of claim 1 1 , so that claim 26 is a allowable for at least 
essentially the same reasons as claim 11, since, as noted above, Ishii does not 
correct the critical deficiencies of the combination of Razavi and de Bellefeuille 
noted above in support of the patentability of claim 1 1 . 



The Examiner asserts that, with respect to claim 1 1 , Appellant argues that 
"[c]laims 1 1 and 19, as well as their dependent claims, should be allowed because 
neither Razavi nor de Bellefuille discloses the feature of 'performing an emergency 
function.'" 

The Examiner also asserts that, with respect to claim 1 1 , Appellant argues that 
"[independent of the above, claims 1 1 and 1 9, as well as their dependent claims, 
should be allowed because neither Razavi nor de Bellefuille disclose the feature of 
'a processing device disposed in the motor vehicle and adapted to perform 
operations including the operations of: configuring the other components; 
maintaining the other components;...'" 

The Examiner asserts that claim 26 recites: 

A service element that belongs to a distributed system in a motor vehicle as a 
component, the distributed system further including other components that are 
independent of one another and interconnected by a bus, the service element 
comprising: 

a processing device disposed in the motor vehicle and adapted to perform 
operations including the operations of: 

automatically, and at predefined intervals, performing an error diagnosis of 
software running on the other components; 

for each of a first subset of errors diagnosed in the error diagnosis step, 
repair the error; and 
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for each of a second subset of errors diagnosed in the error diagnosing 
step, contact a provider and allow the provider to responsively remotely repair 
the error. 

The Examiner asserts that claim 26 contains no limitation requiring "performing 
an emergency function" or "a processing device disposed in the motor vehicle and 
adapted to perform operations including the operations of: configuring the other 
components; maintaining the other components;..." 

As such, the Examiner disagrees with Appellant's indication that "[c]laim 26 
includes subject matter analogous to that discussed above in support of the 
patentability of claim 11" and, without any arguments that are specific to the actual 
limitations of claim 26, the Examiner asserts that Appellant's arguments are not 
considered to be persuasive. Therefore, the Examiner maintains the rejection of 
claim 26, as may best be understood, under 35 U.S.C. 103(a) as being unpatentable 
over Razavi et al. in view de Bellefeuille and Chou et al. and further in view of U.S. 
Patent No. 5,964,813 to Ishii et al. 

• With respect to the rejection of claims 11, 12, 14, 16-21, and 23, as may best be 

understood, under 35 U.S.C. 103(a) as being unpatentable over U.S. Patent No. 

6,185,491 to Gray et al. in view of U.S. Patent No. 6,246,935 to Buckley and further 

in view of U.S. Patent No. 6,330,499 to Chou et al., Appellant argues: 

The Examiner asserts that Gray discloses a service element that maintains 
other components and that Buckley discloses the precise error diagnosis of 
claims 1 1 and 19. However, nowhere does Gray disclose a service element that 
maintains other components as provided for in the present claims. For example, 
the Examiner refers to col. 4, line 65 to col. 5, line 21 of Gray as disclosing a 
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service element that performs upgrading and maintenance of other components 
on a distributed system to which the service element belongs. However, neither 
this section, nor any other section of Gray, discloses a service element that 
maintains other components. What Gray does disclose is a vehicle control center 
that is connected to one or more devices. In order for the vehicle control center to 
"control" a new device that is connected to the vehicle control center, the vehicle 
control center needs an "interface" for that device. "In the simplest 
implementation, illustrated [in FIG. 5], a memory device such as ROM 510 stores 
information about the device and in addition, in one embodiment, contains a 
plurality of JavaBeans 520 for uploading to the vehicle control center over 
bus 120." Gray at col. 4, lines 23-31 (emphasis added). At page 30 of the Final 
Office Action, "the Examiner asserts that Gray explicitly discloses 
upgrading/maintaining the interfaces of the other components by receiving 
software upgrades/updates via a port of the vehicle control center and, as such, 
the vehicle control center (i.e. service element) in Gray performs the operation of 
maintaining the other components, specifically [col. 4, line 65 to col. 5, line 21 
states]: 

As an alternative to storing a control bean 750 and a GUI bean 760 or 
other beans associated with the standard device interface 740, the memory 
device or ROM may store a network address such as a uniform resource 
locator (URL) from which the appropriate manufacturer's interface may be 
downloaded. This permits the manufacturer to update a user interface on a 
dynamic basis and ensure that the most recent version of the manufacturer 
device interface is downloaded when a device is installed. This also reduces 
the ROM space required for storing the manufacturer's interface information 
and reduces the cost of the attached end device. 

One should note that there are a number of ways in which the standard 
device interfaces or custom interfaces can be installed in the vehicle 
control center. They can be pre- installed in the vehicle control center when 
it is installed in the vehicle. Additionally, they can be requested and 
downloaded from the attached devices as described more hereinafter. They 
can be loaded from a diskette, CDROM, EPROM or other memory medium 
into the vehicle control center. They can be received over a network link from 
a URL address which address is either downloaded from the attached device 
or entered manually, and they can be input over an I/O link, such as an 
infrared port to the vehicle control center." 

(Emphasis added.) 

FIG. 5 of Gray refers to uploading the device interface stored in ROM 510 to 
the vehicle control center, and FIG. 7 contrasts that by referring to storing a URL 
for the interface location instead of the interface, so that the vehicle control 
center can upload the URL from the device and download the interface from the 
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location specified by the URL. This says nothing about downloading the interface 
to the device, and in fact, merely discloses the vehicle control center 
downloading the interface, to "be installed in the vehicle control center." 
Additionally, Gray states that the URL embodiment "reduces the ROM space 
required for storing the manufacture's interface information." In FIG. 5, the ROM 
is described as storing the interface (i.e., to upload to the vehicle control center), 
and, in FIG. 7, the ROM is described as storing a URL (i.e., indicating where the 
vehicle control center may retrieve the interface). Presumably, the URL is smaller 
in size than the interface and thus Gray states that FIG. 7 "reduces the ROM 
space required." However, if, as the Examiner contends, the URL is uploaded to 
the vehicle control center so that the vehicle control center can download the 
interface, only to further download the interface to the device (a step wholly 
absent from the disclosure), then the ROM would require more storage space 
than a ROM that only held the interface. 

FIGS. 10A-D further support this, illustrating the vehicle control center with an 
A interface and a B interface, attached to device A and device B. Device C, 
which stores interface C, is connected to the bus, and responsive to a request, 
uploads interface C to the vehicle control center. This is again illustrated in 
FIGS. 11 A, 11B, and 12. Nowhere in Gray does the vehicle control center, nor 
any other device, download to the "other components" a new interface. The only 
thing sent to the components is a request for an upload. See Gray, col. 4, line 65 
to col. 5, line 21 , as cited in the Final Office Action. 

Thus, the system of Gray in view of Buckley, and in view of Chou, does not 
disclose or suggest these features of either of claims 1 1 and 1 9. 



The Examiner maintains that Gray discloses a service element that belongs to a 
distributed system in a motor vehicle as a component, the distributed system further 
including other components that are independent of one another and interconnected 
by a bus, the service element comprising a processing device disposed in the motor 
vehicle and adapted to perform operations including the operation upgrading the 
other components: 



As an alternative to storing a control bean 750 and a GUI bean 760 or other 
beans associated with the standard device interface 740, the memory device or 
ROM may store a network address such as a uniform resource locator (URL) 
from which the appropriate manufacturer's interface may be downloaded. This 
permits the manufacturer to update a user interface on a dynamic basis and 
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ensure that the most recent version of the manufacturer device interface is 
downloaded when a device is installed. This also reduces the ROM space 
required for storing the manufacturer's interface information and reduces the cost 
of the attached end device, (column 4, line 65 to column 5, line 8) 

The Examiner maintains that such a disclosure of upgrading the interfaces of 

each device through the service element meets the limitation for "maintaining the 

other components". 

Additionally, while Appellant argues "[n]owhere in Gray does the vehicle control 
center, nor any other device, download to the 'other components' a new interface", 
the Examiner asserts that claim 1 1 (and 19) does not contain any limitation that 
requires downloading anything to the other components. Specifically, with respect to 
the limitation in question, claim 1 1 (and 19) requires, "a processing device disposed 
in the motor vehicle and adapted to perform operations including the operations of... 
maintaining the other components". The Examiner asserts that one having ordinary 
skill in the art would clearly recognize that providing a processing device that 
updates new interfaces for the other components that allow the other components to 
maintain interaction, communication, and control by/with the processor (i.e. "a 
control bean for the execution of functionality to be performed in the vehicle control 
center to control the device with which the control bean is associated as well as a 
GUI bean which implements a graphical user interface by which the control 
functionality of the control bean may be exercised") meets the limitation of "a 
processing device disposed in the motor vehicle and adapted to perform operations 
including the operations of... maintaining the other components": 



Application/Control Number: 09/913,992 
Art Unit: 2857 



Page 59 



FIG. 2 is a block diagram of an exemplary vehicle network in accordance with 
the invention. The vehicle control center 110, as noted in conjunction with FIG. 
1, controls bus 120. A plurality of devices 200, 210, 220, 230, 240 and 250 are 
illustrated as exemplary attached devices that might commonly be found in a 
network vehicle. Device 200 shows a cabin lighting interface by which the 
vehicle control center can be used to control the lights in the cabin of a vehicle, 
(column 3, lines 33-41) 

FIGS. 6A and 6B show an exemplary alternative device attached to a vehicle 
network and a corresponding software architecture for the alternative device, 
respectively, in accordance with the invention. A more sophisticated attached 
device 600 contains its own CPU or controller and memory 620 connected to the 
bus 120. In this particular implementation, embedded Java 630 can be run using 
CPU 610. A standard application programming interface (API) for automotive 
applications can be defined to standardize the programming interfaces to 
automotive devices. One or more Java™, objects conforming to the API, 
hereinafter called standard device interfaces 640 are stored as JavaBeans™ in 
the memory space of the attached device, (column 4, lines 29-41) 

FIG. 7 illustrates a preferred way in which information can be stored in ROM 
(FIG. 5) or stored in memory (FIG. 6) in accordance with the invention. Typically, 
a device ID 700 will be stored. The device ID may contain information such as 
an identification of the manufacturer 710, a model number 720, a serial number 
of the device 730 and other information. In one embodiment, one or more 
standard device interfaces 740, such as standard device interface 1 or standard 
device interface N may be stored. In a preferred embodiment, each standard 
device interface includes a control bean for the execution of functionality to be 
performed in the vehicle control center to control the device with which the 
control bean is associated as well as a GUI bean which implements a graphical 
user interface by which the control functionality of the control bean may be 
exercised, (column 4, lines 50-64) 



• Appellant argues: 

Each of claims 11 and 19 also recites, inter alia, "allowing a remote diagnosis 
of the other components of the distributed system to be carried out, wherein the 
remote diagnosis includes testing at least one of the other components." 

As regards this feature, neither Gray nor Buckley discloses "the remote 
diagnosis includes testing at least one of the other components." Instead, the 
Examiner relies on Chou at col. 3, lines 15-31 and col. 5, lines 34-35. However, 
the remote service center 200 (including diagnostic server 201) is thoroughly 
discussed at Chou col. 5, line 33 to col. 6, line 47, and does not mention "wherein 
the remote diagnosis includes testing at least one of the other components." 
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"Diagnostic server 201 [may have] access to data related to the vehicle such as 
history, as-built, diagnostics, warranty, service information and failure mode 
data." (Chou, col. 5, lines 35-37.) The section goes on to further describe data 
collection and modeling, but nowhere does Chou disclose a "remote diagnosis 
[that] includes testing at least one of the other components." 

The Examiner asserts that, as explained above with respect to the outstanding 
35 U.S.C. 112, first paragraph, rejection, the limitation of "allowing a remote 
diagnosis of the other components of the distributed system to be carried out, 
wherein the remote diagnosis includes testing at least one of the other components" 
is rejected as lacking enablement due to the specification not clearly supporting 
and/or distinguishing each of "performing an error diagnosis", "allowing remote 
diagnosis" and "testing at least one of the other components". 

The Examiner also asserts that, in the Appeal Brief on page 6, Appellant 
indicates that "diagnosis/testing is known in the art", "a diagnosis/testing itself for any 
particular implementation would be understood by one of ordinary skill in the art", "it 
is understood from the plain meaning of the terms that testing is a subset of carrying 
out remote diagnosis", "To perform a diagnosis means to identify the nature or cause 
of a phenomenon.", "A step in performing such identification may include performing 
a test", and "The actual diagnosis routines and test routines are well known in the 
art, and selected based on context of specific implementation" but now Appellant 
argues the merits of "testing" and indicates that while Chou discloses a "diagnostic 
server", Chou does not specifically teach that such diagnosis includes testing. 

Additionally, the Examiner also asserts that with respect to the limitations in 
question in the rejection of claims 1 1 and 19, as may best be understood, under 35 
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U.S.C. 103(a) as being unpatentable over U.S. Patent No. 6,185,491 to Gray et al. in 

view of U.S. Patent No. 6,246,935 to Buckley and further in view of U.S. Patent No. 

6,330,499 to Chou et al., the rejection relies on the invention of Gray and Buckley to 

teach a communication element for loading new software interfaces for the plurality 

of other components, and the invention of Chou is only relied upon for teaching 

allowing a remote diagnosis of the plurality of components of the distributed system, 

wherein the remote diagnosis includes testing. 

The Examiner than maintains that Chou does teach an arrangement for allowing 

a remote testing and diagnosis of the plurality of components of the system, by 

providing remote diagnosis of a plurality of components connected to a service 

element "1 20" on a vehicle bus "1 04" wherein a diagnosis server diagnoses/tests the 

plurality of components by obtaining data regarding the plurality of components 

through the service element, specifically: 

The processor is integrated with a network interface 320 to provide 
communication capability with the remote service center 200. Preferably, the 
network interface comprises a removable wireless telephone such as the 
Motorola i1 000+ and a docking facility for the wireless phone integrated with the 
client computer device. Both voice and data connections can be supported by 
interfacing the processor 300 and the wireless phone. The telephone integration 
provides basic communication functions. It establishes a data (e.g. TCP/IP) 
connection with a remote service center (e.g., remote service center 200). 
Wireless technologies such as GSM (Global System for Mobile 
Communications), CDMA (Code Division Multiple Access), TDMA (Time Division 
Multiple Access), iDEN.TM. (a TDMA-based Motorola technology), and AMPS 
(Advanced Mobile Phone System) can all be supported. The phone may also be 
used for wireless voice communications, (column 3, lines 15-13) 



The vehicle bus interface 120 is responsible for replying to requests for 
parametric data. It is also responsible for continuously monitoring the vehicle 
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bus 104 for any fault reported by the ECUs 103, in terms of diagnostic trouble 
codes (DTCs). (column 4, lines 15-20) 

The in-vehicle system establishes a data connection, using a cellular phone 
102, with a diagnostic server 201 at the service center 200, collects diagnostic 
data using the diagnostic data service 120A, and uploads a snapshot of the 
vehicle data (e.g. VIN, test data with time-stamp) to the diagnostic server 201 . 
The in-vehicle system may need to interact with the server 201 throughout a 
diagnosis or health checkup session, collecting and providing additional vehicle 
information as requested by the server 201 . The result from the server 201 
indicates either that the vehicle is in good health with no urgent action required, 
or that one or more problems requiring immediate attention are detected. 

When the vehicle is deemed to be in good health, a report enumerating the 
items checked and the conditions of those items is provided to the client 
computer device and reported to the driver or user using TTS and the display, 
(column 5, lines 1-15) 

In step 7, the diagnostic server requests additional information (e.g. vehicle 
parametric data) from the diagnostic client 421 . Then, in step 8, the diagnostic 
client requests the data from the diagnostic data service 120A. 

In step 9, the diagnostic data service interrogates the ECUs 103 via the 
vehicle bus adapter 120C for the requested data. 

Then, in step 1 0, the ECUs 1 03 provides the requested data. In step 1 1 , the 
data is returned to the diagnostic client 421, and thereafter, in step 12, the data is 
in turn transmitted to the diagnostic server 201 . Steps 7 through 12 may be 
repeated to obtain all of the relevant vehicle data, (column 8, lines 22-33) 



Application/Control Number: 09/913,992 
Art Unit: 2857 



Page 63 




• Appellant provides no arguments with respect to the rejection of claims 22 and 
26, as may best be understood, under 35 U.S.C. 103(a) as being unpatentable over 
Gray in view of Buckley and Chou and further in view of U.S. Patent No. 4,866,713 
to Worger et al. and, as such, the Examiner maintains the outstanding rejection. 
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(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 

For the above reasons, it is believed that the rejections should be sustained. 

Respectfully submitted, 

/Jeffrey R. West/ 

Primary Examiner, Art Unit 2857 
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